Add tests for ti:self JWT scope enforcement on execution API#66071
Merged
Conversation
The ti:self scope check at security.py rejects requests where the JWT subject does not match the task_instance_id in the path. This is the cross-task isolation guarantee for any router that opts into ti:self (e.g. /task-instances, /hitl, and the upcoming task state endpoints from AIP-103). Until now the check was uncovered. Adds three tests mirroring the existing TestTokenTypeScopeEnforcement pattern: matching subject is accepted, mismatched subject returns 403, and routes without ti:self ignore subject mismatches.
1 task
Contributor
Author
potiuk
approved these changes
May 10, 2026
jason810496
pushed a commit
to jason810496/airflow
that referenced
this pull request
May 11, 2026
…66071) * Add tests for ti:self JWT scope enforcement on Execution API The ti:self scope check at security.py rejects requests where the JWT subject does not match the task_instance_id in the path. This is the cross-task isolation guarantee for any router that opts into ti:self (e.g. /task-instances, /hitl, and the upcoming task state endpoints from AIP-103). Until now the check was uncovered. Adds three tests mirroring the existing TestTokenTypeScopeEnforcement pattern: matching subject is accepted, mismatched subject returns 403, and routes without ti:self ignore subject mismatches. * update
3 tasks
potiuk
added a commit
to apache/magpie
that referenced
this pull request
May 14, 2026
Replaces the existing scope-based @-mention routing in security-issue-triage with a history-based priority order: 1. PR-author of the analogous prior fix (via gh search prs) 2. Recent reviewer of the area (via gh pr list reviewed-by) 3. Scope-default fallback (existing behavior, narrowed to 1 pick) The routing decision is cached per unique code area within a bulk-mode run so a 5-tracker sweep through one directory issues one set of gh search prs queries, not five. Adds an explicit routing-failure fallback: when no PR-history match exists for a code area, the skill stops and surfaces a "confirm @-mentions before posting" prompt rather than silently defaulting to a generic roster ping. Motivation: scope-default routing produces generic 3-person pings that the team trains itself to ignore. For airflow-s#406 (missing ti:self enforcement on /execution/task-reschedules) the right pick was unambiguous — @amoghrajesh wrote apache/airflow#66071 introducing the mechanism — but the existing scope-default rule produced a generic providers ping. This PR codifies the priority order so the classifier reaches the same answer the human triager reaches by hand. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ti:self scope check at security.py rejects requests where the JWT subject does not match the task_instance_id in the path. This is the cross-task isolation guarantee for any router that opts into ti:self (e.g. /task-instances, /hitl, and the upcoming task state endpoints from AIP-103). Until now the check was uncovered.
Adds three tests mirroring the existing TestTokenTypeScopeEnforcement pattern: matching subject is accepted, mismatched subject returns 403, and routes without ti:self ignore subject mismatches.
Why
execution API uses the
ti:selfscope to enforce that a task can only access its own resources — JWT subject must equal thetask_instance_idin the request path. The check lives at https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/api_fastapi/execution_api/security.py#L185-L193 and is what stops a task from reading or writing another task's state, HITL responses, etc.I noticed that
test_security.pyonly tested token-type enforcement (workload vs execution); the cross-TI check was relying on no one breaking it.While working on AIP-103 (task / asset state endpoints), I needed this guarantee to be defended before claiming that "a task can only access its own state" is true. Filing this separately so the coverage benefits every router using
ti:self, not just the state endpoints.Summary
Adding tests for three cases:
Was generative AI tooling used to co-author this PR?
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.